home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 098 / cstd.arc / CSTD8#3 < prev    next >
Encoding:
Internet Message Format  |  1985-07-28  |  14.0 KB
  1. From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
  2.  
  3.  
  4. mod.std.c Digest            Mon,  1 Jul 85       Volume 8 : Issue   3 
  5.  
  6. Today's Topics:
  7.          (B.1.1.2, C.8) Use of Whitespace in the Preprocessor
  8.                  (B.2.2) Character display semantics
  9.                      (B.2.4.1) Translation limits
  10.               (B.2.4.2, D.1, etc.) Quasi-reserved words.
  11.                       (C.8.2) Macro replacement
  12.                     (C.8.3) Conditional inclusion
  13.         (D.) Operating-system defined values and C data types.
  14.                             (D.10.2) Rand
  15.                           (D.12.3.1) asctime
  16.                           (D.12.3.4) gmtime
  17.                   (D.3) Character Testing Functions
  18.                        (D.8) Variable arguments
  19.                         (D.9.9) File pointers
  20. ----------------------------------------------------------------------
  21.  
  22. Date: Sun, 30 Jun 85 12:45:44 edt
  23. From: decvax!minow (Martin Minow)
  24. Subject: (B.1.1.2, C.8) Use of Whitespace in the Preprocessor
  25. To: std-c@cbosgd
  26.  
  27. Comments on ANSI C Draft Standard (X3J11/85-045, April 30, 1985).
  28. **
  29. ** Note: these are my personal comments and not necessarily those
  30. ** of my employer.
  31. **
  32.  
  33. There seems to be some confusion (in my mind anyways) regarding
  34. the interaction of "tokenization" (sec B.1.1.2) and the preprocessor.
  35. According to the description of translation phases (phases 1 and 2
  36. are irrelevant to this discussion):
  37.   Phase
  38.    3. Comments are replaced by one space character.
  39.    4. The source text is completely tokenized... Each sequence
  40.       of other [not newline] white-space characters becomes a single
  41.       white-space token; alternatively, each other white-space
  42.       token becomes a unique token.  [I don't understand this and
  43.       aren't sure that "alternatives" are appropriate here.]
  44.    5. The source text is preprocessed.
  45.  
  46. However, in the description of the preprocessor (sec C.8),
  47.    "there may be any number of space and horizontal-tab characters
  48.    between the # token and the identifier that constitutes the next
  49.    token, and before the new-line character that terminates the directive."
  50.  
  51. Some questions:
  52.  
  53. 1.  If I understand the translation phases correctly, there are no
  54.     "space and horizontal-tab characters", but rather "white-space
  55.     tokens."  By explicitly specifying space and tab, and not
  56.     specifying the other two white-space characters (vertical-tab
  57.     and form-feed), it appears that the translation phase description
  58.     should be changed as follows:
  59.     3. ... Each comment is replaced by one <SPACE> token.  Space and
  60.        horizontal-tab characters are replaced by <SPACE> tokens.
  61.        Vertical-tab and form-feed characters are replaced by <FEED>
  62.        tokens.
  63.     6. ... The preprocessing concatenation operation is applied and the
  64.        full source is retokenized.  <FEED> tokens become <SPACE> tokens.
  65.  
  66.     While this appears to clarify the intent of the Draft Standard,
  67.     it would seem simpler to drop all distinction between the
  68.     various white-space tokens.  It would also eliminate confusion
  69.     if the Draft Standard were to emphasize that comments may
  70.     be placed anywhere in preprocessor command lines and may
  71.     also cause such lines to extend over more than one physical
  72.     input source line.  For example, comments are legal in the
  73.     following contexts:
  74.       /*1*/ # /*2*/ include /*3*/ "filename" /*4*/
  75.     and any of these comments may extend over multiple source lines.
  76.  
  77. ------------------------------
  78.  
  79. Date: Sun, 30 Jun 85 12:45:44 edt
  80. From: decvax!minow (Martin Minow)
  81. Subject: (B.2.2) Character display semantics
  82. To: std-c@cbosgd
  83.  
  84. Section B.2.2 states that
  85.  
  86.   "The effect of writing a printable character ... to a display device
  87.   is to display a graphic representation of that character at the current
  88.   printing position and then advance the printing position to the next
  89.   position on the current line."
  90.  
  91. I would recommend adding:
  92.  
  93.   "The effect of writing a printable character at the final printing
  94.   position of a line is implementation defined."
  95.  
  96. I would recommend deleting \a and \v as they offer no useful capability
  97. and cannot be implemented in an implementation-independent manner.
  98.  
  99. I would recommend that, for all \ escapes except \n, the Standard
  100. provide a definition in terms of the draft ISO DIS 8859/1 (or the
  101. equivalent draft ANSI X3.134.2 and approved ECMA-94) 8-bit code
  102. standards, with reference to the earlier ANSI X3.4-1977, ISO 646,
  103. ISO dis 2022.2, etc. standards and that all actions be labeled
  104. "implementation dependent."  \n should have the semantics described
  105. in (B.2.2) and the Draft Standard should note that the semantics of
  106. the ANSI line-feed code (code position 0/10) are implementation-dependent.
  107. (I.e, putchar('\n') is not necessarily equivalent to putchar(0xA)).
  108. this section might be rewritten in roughly the following manner:
  109.  
  110.   The preferred implementation character set for C is specified in
  111.   draft ISO DIS 8859/1, called Latin-1 in this Draft Standard.  If
  112.   the implementation supports the Latin-1 character set, escape codes
  113.   have the following representation:
  114.  
  115.     Escape  ANSI code  Action
  116.       \a      0/7       Audible alert
  117.       \b      0/8       Backspace
  118.       \f      0/12      Form feed
  119.       \r      0/13      Carriage return without advance to new line
  120.       \t      0/9       Horizontal tab
  121.       \v      0/11      Vertical tab
  122.  
  123.   If the implementation does not support the Latin-1 character set,
  124.   the above escapes have implementation-dependent value and actions.
  125.   They must, however, describe different character values (so that
  126.   case statements will not fail.)
  127.  
  128. It should be noted that on a display device implementing ANSI standard
  129. character set invocation and designation, that "putchar('a')" does not
  130. necessarily display the first character of the roman alphabet in lower
  131. case. The presentation layer of the display device will show its
  132. representation of the character currently invoked into GL at position
  133. 6/1. Actually, since devices can interpret information between the
  134. DCS, OSC, APC, or PM introducers and the ST delimiter in just about
  135. any way they please, it does not even promise to display anything!
  136.  
  137. Should the standard (especially an ANSI one) promise more than 
  138. sending the bit pattern to the display device? Perhaps "\n" should be
  139. special.
  140.  
  141. ------------------------------
  142.  
  143. Date: Sun, 30 Jun 85 12:45:44 edt
  144. From: decvax!minow (Martin Minow)
  145. Subject: (B.2.4.1) Translation limits
  146. To: std-c@cbosgd
  147.  
  148. Section B.2.4.1 states that "the implementation must be able to compile
  149. at least one program that meets or exceeds all of the following
  150. translations limits."  Note, however, that a program with 15 nesting
  151. levels for compounds, 31 character identifiers, and 1024 identifiers
  152. in each nested block will require about 500,000 bytes of symbol table
  153. storage which is probably not feasible for any but the largest
  154. implementation.  I would suggest removing "all" or changing "maximum
  155. number of identifiers with block scope in one block" to "... in one
  156. block and all of its parents.", if for no other reason than making it
  157. unnecessary for implementors to ignore this portion of the standard.
  158.  
  159. The following translation limits seem unreasonably small:
  160.  
  161.     Conditional compilation nesting levels (6) -- I would recommend 16.
  162.  
  163.     Case labels in a switch (255) -- I would recommend at least 512
  164.     and preferably 1024.  The yacc grammar for Pascal offers an
  165.     example of a large switch statement.
  166.  
  167. ------------------------------
  168.  
  169. Date: Sun, 30 Jun 85 12:45:44 edt
  170. From: decvax!minow (Martin Minow)
  171. Subject: (B.2.4.2, D.1, etc.) Quasi-reserved words.
  172. To: std-c@cbosgd
  173.  
  174. The Draft Standard has added a large number of #defined symbols
  175. and type definitions.  For example, section B.2.4.2 adds 30 numerical
  176. limits.  I would recommend that all new definitions (i.e. #defined
  177. symbols and type definitions that are not currently in widespread
  178. use) be specified with a leading _ so they cannot conflict with
  179. user code.  I.e., the user should have a reasonable chance of defining
  180. variables can never conflict with reserved words.   As it is now,
  181. there is no way that I can tell that a symbol does not conflict
  182. with a symbol in some library header file.
  183.  
  184. I would further recommend that the symbols be composed of full English
  185. words, even if this means more typing.  Thus "SHRT_MIN" should be
  186. "_SHORT_MIN".
  187.  
  188. Similarly, I would recommend "readonly" rather than "const."
  189.  
  190. ------------------------------
  191.  
  192. Date: Sun, 30 Jun 85 12:45:44 edt
  193. From: decvax!minow (Martin Minow)
  194. Subject: (C.8.2) Macro replacement
  195. To: std-c@cbosgd
  196.  
  197. The current Draft Standard added the following to C.8.2:
  198.  
  199.     If the identifier following the initial # in a directive has been
  200.     defined as a macro name, the identifier is not replaced by an expansion
  201.     of the macro.
  202.  
  203. I think this means that if you have written
  204.  
  205.     #define foo endif
  206.     #foo
  207.  
  208. you don't get #endif, but an example would be helpful.
  209.  
  210.  
  211. (C.8.2) ## unclarities.
  212.  
  213. It appears from my reading that the token created by ## concatenation
  214. cannot cause further macro expansion, but this is not clearly stated.
  215. For example, what is the result of the following:
  216.  
  217.     #define concat(a, b) a ## b
  218.     #line 123
  219.     int line = concat(__LI, NE__);
  220.  
  221. is it
  222.     line = __LINE__;
  223. or
  224.     line = 123;
  225.  
  226. ------------------------------
  227.  
  228. Date: Sun, 30 Jun 85 12:45:44 edt
  229. From: decvax!minow (Martin Minow)
  230. Subject: (C.8.3) Conditional inclusion
  231. To: std-c@cbosgd
  232.  
  233.             #if directives verified for correctness?
  234.  
  235. The Draft Standard now specifies that
  236.  
  237.     Directives are verified for correctness, but processed only to keep
  238.     track of the level of nested conditionals.  Does this mean that
  239.  
  240.         #if 0
  241.         /* never compiled */
  242.         #if )syntax error(
  243.         #endif
  244.         #endif
  245.  
  246.     should print a compiler error message?  What about
  247.  
  248.         #undef never_defined
  249.         #ifdef never_defined
  250.         #define xyz(a)  ((a) * 1)
  251.         #endif
  252.         ...
  253.         #ifdef never_defined
  254.         #if xyz(123)
  255.         #endif
  256.         #endif
  257.  
  258.    Should the use of xyz() result in an error message, or be replaced
  259.    by zero (undefined preprocessor symbol) or what?
  260.  
  261. ------------------------------
  262.  
  263. Date: Sun, 30 Jun 85 12:45:44 edt
  264. From: decvax!minow (Martin Minow)
  265. Subject: (D.) Operating-system defined values and C data types.
  266. To: std-c@cbosgd
  267.  
  268. Several functions (notably fseek/ftell and kill) take parameters
  269. that are defined in terms of C data types (the ftell result is
  270. a long, and kill takes an integer program identifier).  This
  271. cannot be made to work correctly on many systems.  For example,
  272. a process is specified on RSX-11M by a 3 (16-bit) word vector.
  273. Since the language supports passing structures to functions,
  274. I would recommend redefining these functions in terms of
  275. structures (whose contents are defined by appropriate #include
  276. files) and adding functions to perform implementation-dependent
  277. arithmetic in an implementation-dependent manner.
  278.  
  279. ------------------------------
  280.  
  281. Date: Sun, 30 Jun 85 12:45:44 edt
  282. From: decvax!minow (Martin Minow)
  283. Subject: (D.10.2) Rand
  284. To: std-c@cbosgd
  285.  
  286. The definition of rand semantics is reasonable for systems
  287. with 32-bit two's-complement long integers.  It is not clear
  288. from Knuth (volume 2) that it will yield the same
  289. sequence of numbers for implementations with greater numeric
  290. precision or different arithmetic behavior.
  291.  
  292. Unless, of course, rand is implemented as a function that reads
  293. a file of 2^32 pre-compiled integers.  But, since the size of this
  294. file cannot be expressed as a long, srand cannot correctly reposition
  295. the file.
  296.  
  297. ------------------------------
  298.  
  299. Date: Sun, 30 Jun 85 12:45:44 edt
  300. From: decvax!minow (Martin Minow)
  301. Subject: (D.12.3.1) asctime
  302. To: std-c@cbosgd
  303.  
  304. In order to provide for orderly development of local-language
  305. variants of C, the alphabetic words in the returned string
  306. should be standardized to their current (English) values --
  307. which should be included in the Draft Standard.  Alternatively,
  308. the Standard should explicitly state that the actual contents of
  309. these fields may be implementation dependent.  I would prefer the former.
  310.  
  311. ------------------------------
  312.  
  313. Date: Sun, 30 Jun 85 12:45:44 edt
  314. From: decvax!minow (Martin Minow)
  315. Subject: (D.12.3.4) gmtime
  316. To: std-c@cbosgd
  317.  
  318. The standard should note that Greenwich Mean Time is more properly
  319. known as UTC (Universal Coordinated Time.)
  320.  
  321. [ You mean UCT? -- Mod -- ]
  322.  
  323. ------------------------------
  324.  
  325. Date: Sun, 30 Jun 85 12:45:44 edt
  326. From: decvax!minow (Martin Minow)
  327. Subject: (D.3) Character Testing Functions
  328. To: std-c@cbosgd
  329.  
  330. The "~" character has the hexadecimal value 0x7E, not 0xFE.
  331. The DEL character has the hexadecimal value 0x7F, not 0xFF.  As
  332. noted above, they should be defined in terms of the Latin-1 alphabet
  333. and a particular set of presentation layer designations/invocations
  334. (ASCII_G in GL, Latin-1 in GR). This avoids all of the issues with NRC's.
  335.  
  336. I would suggest that the C Standards Committee coordinate with
  337. the X3 character set committees.
  338.  
  339. ------------------------------
  340.  
  341. Date: Sun, 30 Jun 85 12:45:44 edt
  342. From: decvax!minow (Martin Minow)
  343. Subject: (D.8) Variable arguments
  344. To: std-c@cbosgd
  345.  
  346. This section refers to section C.7.7.1, which doesn't exist.
  347.  
  348. What is the behavior of an implementation when number and
  349. type of the arguments, as accessed by va_arg disagree with
  350. those of the actual function call?
  351.  
  352. ------------------------------
  353.  
  354. Date: Sun, 30 Jun 85 12:45:44 edt
  355. From: decvax!minow (Martin Minow)
  356. Subject: (D.9.9) File pointers
  357. To: std-c@cbosgd
  358.  
  359. Defining the value returned by ftell() as a long cannot work
  360. on some implementations and unnecessarily limits the size of
  361. files on all implementations.  I would recommend that ftell return
  362. an implementation-defined structure and that functions be
  363. provided to manipulate the values of such structures.
  364.  
  365. ------------------------------
  366.  
  367. End of mod.std.c Digest - Mon,  1 Jul 85 10:23:12 EDT
  368. ******************************
  369.